In a wireless network that includes a plurality of wireless access points, a client device may roam between those access points.
During the initial connection of the client device to a wireless access point of the wireless network, the client device and the access point must complete a 4-way key management procedure. This handshake process confirms the mutual possession of a Pairwise Master Key (PMK) that they use to generate encryption keys, including a Pairwise Transient Key (PTK). During a 4-way handshake, the access point sends an authenticator nonce value (ANonce) to the client device. The ANonce is pseudo-randomly generated number that is used once. The client device then constructs and installs a Pairwise Transient Key (PTK) using the PMK, the ANonce, a client device nonce value (SNonce), the access point's media access control (MAC) address, and the client device's MAC address. The client device then sends the SNonce and a Message Integrity Code (MIC) generated using the PTK to the access point. The access point then derives and installs the PTK on its end and can validate the MIC that it received. The access point then sends a Group Temporal Key (GTK) and another MIC to the client device. The client device can validate the MIC that it received and install the GTK. Finally, the client device sends an acknowledgement message to the access point. The result of this 4-way handshake is that the client device and the access point have each installed the same PTK and GTK and are ready for encrypted communication between themselves. This 4-way handshake may be used to establish encrypted Wi-Fi Protected Access II (WPA-2) communication between the client device and the access point.
However, as a client device roams through a wireless network that contains a plurality of access points, the same 4-way handshake needs to be performed whenever the client device roams between a first access point and a second access point. The overhead of the 4-way handshake can degrade communication and performance of the wireless network, as the client device needs to repeatedly perform the 4-way handshake as it roams across access points.
Moreover, existing techniques for client roaming between access points require the client device to determine which access point to connect to in the wireless network, and the access points cannot control which access point is going to manage communication with the client device. Thus, if a particular access point is experiencing a significant load, or other performance issues, the wireless network is incapable of forcing the client device to roam to a different access point.
The 802.11v standard attempts to provide access points with improved control over which access point is going to manage communication with the client device. Under 802.11v, an access point may send a Basic Service Set Transition Message (BSS Transition Message) which tells the client device the other access points it can connect to. However, under 802.11v, the client device has control over which specific access point, of the access points identified in the BSS Transition Message, it will connect to next. Thus, the 802.11v does not provide complete control to the access points to determine which access point is going to manage communication with the client device. Moreover, implementation of 802.11v requires installation of new protocol-compliant code or updates on the client device.
The 802.11r Fast Roaming (FT) protocol attempts to provide for improved roaming of client devices, but the protocol requires installation of new protocol-compliant code or updates on client devices. Additional existing techniques for providing seamless roaming between access points requires either a controller-based architecture or requires open service set identifiers (SSIDs) rather than encrypted SSIDs.
Thus, what is needed are techniques for seamless roaming of a client device in between access points with WPA-2 encryption that solves these issues.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
While each of the figures illustrates a particular embodiment for purposes of illustrating a clear example, other embodiments may omit, add to, reorder, and/or modify any of the elements shown in the figures.